REMARKS 

Claims 67-75 and 92-98 are pending in the application. 

Rejection of Claims 67-75 and 92-98 for Lack of Written Description 

Claims 67-75 and 92-98 stand rejected under 35 U.S.C. § 1 12, lf1 as failing to 
comply with the written description requirement. The application discloses that a 
"shopper using a computer with a Domain Name System (DNS) entry in New York vs. 
Washington vs. Colorado entering the same domain name to access may also receive 
different displayed information." P. 4, In. 27 to P. 5, In. 1 . The Office Action states the 
application "does not have support to enable one of ordinary skill in the art to use 
applicant's claimed and argued invention to use DNS to determine the current location 
of the user." In other words, the Office Action asserts one of ordinary skill would not 
have known how to determine the location of the remote computer using only its DNS 
entry (i.e., IP address). 

While IP addresses do not contain any geographic information and are assigned 
without regard to geographic location, at the time the application was filed, several 
methods of determining the location would have been available to and known by one of 
ordinary skill. In other words, if asked to determine the location of a remote system 
based on its IP address, would one of ordinary skill in the art at the time the application 
was filed (February 22, 2000) have known how to make that determination using any 
one of the following exemplary tools. 

The domain name system ("DNS") is fundamental to the transfer of information 
across the Internet. The DNS includes name servers that map each domain name to an 
IP address. Whenever a user (such as the shopper) enters a domain address, one or 
more name servers are queried to determine the IP address of the host system 
associated with the domain name. "[I]nverse inquires [in which an IP address is 
presented to the DNS system] have been part of the domain system since it was first 
specified...." Douglas E. Comer, Internetworking with TCP/IP Vol 1: Principles, 
Protocols, and Architecture, 329-331 (2 nd Ed. 1991). This reference also explains how 
to formulate a "pointer query" to determine the domain name associated with an IP 
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address. As this was known for at least ten years before the filing of the present 
application, it was surely known by one of ordinary skill in the art who is presumed to 
have knowledge of the prior art. Therefore, using only the IP address, one of ordinary 
skill would have known how to obtain the domain name associated with that IP address. 

The domain name itself may include location information. In such circumstances, 
the inverse DNS lookup alone could be used to determine the location of the remote 
computer. An example of such a query is provided on page 12 of applicant's May 30, 
2006 response to Examiner's request for information under 37 CFR 1 .105. In this 
example, a lookup of the IP address 24.128.70.33 identified the domain name c-24-128- 
70-33.hsd1.nh.comcast.net, which indicates it is located in "nh" or New Hampshire. 

The attached A Primer on Internet and TCP/IP Tools, published in 1994 , 
describes a tool named "nslookup" which may be used to perform the inverse DNS 
lookup. G. Kessler and S. Shepard, A Primer on Internet and TCP/IP Tools, Request 
for Comment (RFC) No. 1739, The Internet Engineering Task Force, Networking 
Working Group (December 1994). If the Examiner is using MS Windows and wishes to 
use nslookup, simply do the following: 

1. Go to the "Start" button; 

2. Select "All Programs;" 

3. Select "Accessories;" 

4. Within "Accessories," select the "Command Prompt;" 

5. Enter the following command into the "Command Prompt" window: 
nslookup 24.128.70.33. 

The following results should appear: 
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If the Examiner experiences difficulty verifying this result, the Examiner is invited 
to contact the undersigned at (206) 757-8133. 

Another example of a method of using the IP address to determine a location 
(also explained in applicant's May 30, 2006 response to Examiner's request for 
information under 37 CFR 1 .105) includes using the "traceroute" tool which may be 
used to map the route taken by packets communicated from the remote computer to the 
host system and vise versa. Amendment, filed May 30, 2006, pp 15-16. Please see 
attached A Primer on Internet and TCP/IP Tools, which clearly demonstrates traceroute 
was a well known tool before the filing of the present application. Page 8 provides an 
explanation of an example traceroute result shown on page 9. The explanation clearly 
identifies the communication is carried on a regional New Jersey network immediately 
prior to delivery to its destination, Bellcore in Red Bank, New Jersey. Therefore, 
information obtained using traceroute could be used to infer the location of the remote 
computer, which in this case was New Jersey. 
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If the Examiner is using MS Windows and wishes to use traceroute (which 
corresponds to the "tracert" command in Windows), simply do the following: 

1 . Go to the "Start" button; 

2. Select "All Programs;" 

3. Select "Accessories;" 

4. Within "Accessories," select the "Command Prompt;" 

5. Enter the following command into the "Command Prompt" window: 
tracert 216.254.14.142. 

Results similar to those shown below should appear. Because the Examiner's 
route to 216.254.14.142 starts from a different location than that indicated below, the 
Examiner's tracert results will not be identical to those shown. Please note, like the 
results in applicant's May 30, 2006 response to Examiner's request for information 
under 37 CFR 1 .105, these results indicate the nearest backbone router is in Seattle. 
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Another exemplary method involves looking up the IP address in the American 
Registry for Internet Numbers ("ARIN") database. ARIN was established in 1997 as one 
of five regional internet registries for IP addresses (not domain names). ARIN's service 
region includes the United States. At the time the application was filed, the ARIN 
database could be queried for information related to the owner of an IP address. An 
online version can be viewed today at http://www.arin.net/index.shtml . As explained in 
applicant's May 30, 2006 response to Examiner's request for information under 37 CFR 
1.105, a search of the network name portion of the IP address 24.127.74.33, which is 
24.127.0.1 , indicated the network was located in Los Angeles. However, applicant 
notes that the ARIN database now indicates the location of the network is Richmond. 
Applicant invites the examiner to visit the ARIN website and enter the IP address of the 
exemplary remote computer and/or its network to view the results of such a query. 

Another exemplary method involves using a "whois" tool, described on page 17 
of the attached A Primer on Internet and TCP/IP Tools. The whois tool returns point-of- 
contact information such as the address of the registrant and/or the address of the 
administrative contact. See also Amendment, filed May 30, 2006, pp 12. Therefore, 
whois is yet another tool that would have been known to and used by those of ordinary 
skill at the time the application was filed. 

Obviously, more than one of these methods may be used to increase the 
confidence of the host system that the correct location was determined. Therefore, one 
of ordinary skill would have known how to determine the location of a remote computer 
given only its IP address and a detailed description of such methods is not necessary to 
enable the invention recited by the pending claims. Applicant notes that Claims 92-96 
and 98 do not recite how the location is determined. Instead, these claims recite the 
determination of additional information about the computer based on the network 
address of the computer. As discussed above, the IP address can be used to 
determine additional information about the computer (including its location, 
communication routing information, registrant information, etc.). Consequently, 
applicant respectfully requests withdrawal of the rejection under Section 112 with 
respect to claims 67-75 and 92-98. 
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Rejection of Claims 67-75 and 92-98 as Obvious 

Claims 67-75 and 92-98 stand rejected under 35 U.S.C. § 103(a) as 
unpatentable over U.S. Patent No. 6,332,127 issued to Bandera et al. in view of U.S. 
Patent No. 6,286,045 issued to Griffiths et al. As indicated in the Office Action, Bandera 
et al. does not teach a presentation formulator configured to formulate tailored store 
screens to be displayed on the remote computers of shoppers. Griffiths et al. teaches a 
method of selecting a banner for display on a web page that more accurately counts the 
number of times the banner is displayed. The method involves sending a banner 
request signal from the user's terminal to a recipient that serves a banner to the user's 
terminal. Col. 15, Ins. 4-18. Griffiths et al. does not teach either a store or using the 
location of the user's terminal to formulate tailored store screens. At least because 
Bandera et al., Griffiths et al., and a combination thereof all fail to teach this element of 
the claims, applicant respectfully request withdrawal of this rejection. 

With respect to claims 68-71 , neither Bandera et al. nor Griffiths et al. mention a 
search request entered by the shopper into the shopper's computer to navigate to the 
host system to initiate the current communication. Therefore, neither reference nor a 
combination thereof renders the invention of these claims obvious. 

With respect to claim 72, neither Bandera et al. nor Griffiths et al. mention the 
location of the shopper's computer at the time of the current communication, as 
determined by the shopper data collector, is used by the shopper data collector to 
determine for the current communication particular traits, habits, or interests of the 
shopper or other pertinent shopper information. Griffiths does not mention using the 
location of the user for any purpose and Bandera et al. discusses adapting the 
advertisements based only on location, and time, user traits, habits, and interests are 
never discussed. Therefore, neither reference nor a combination thereof renders the 
invention of claim 72 obvious. 

With respect to claim 94 and 96, Bandera et al. never mentions using DNS. 
Instead, the reference discusses using GPS, a telephone trace, a cellular base station, 
and a satellite beam to determine additional information about the computer that is in 
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addition to the identity of the computer's network address. See Col. 6, Ins. 49-51 ; Col. 
6, Ins. 62-66; Col. 7, Ins. 1-8. While Griffiths mentions DNS, it is for the purposes of 
locating banners to send to the user, not to determine the location of the user. 
Therefore, neither reference nor a combination thereof renders the invention of claims 
94 and 96 obvious. 

Commissioner is hereby authorized to charge any additional fees if believed 
necessary, or to charge any deficiency or credit any overpayment to Deposit Account 
No. 04-0258. 

All of the claims remaining in the application are now believed to be allowable. 
Favorable consideration and a Notice of Allowance are earnestly solicited. 

If questions remain regarding this application, the Examiner is invited to contact 
the undersigned at (206) 757-8133. 

Respectfully submitted, 

Richard A. Leeds 

DAVIS WRIGHT TREMAINE LLP 


B y /George C. Rondeau, Jr./ 
George C. Rondeau, Jr. 
Registration No. 28,893 

1201 Third Avenue, Suite 2200 
Seattle, Washington 98101 
Phone: (206)757-8133 
Fax: (206)757-7133 
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We said that the client takes responsibility for the expansion of such abbreviations, 
but it should be emphasized that such abbreviations are not part of the domain name 
system itself. The domain system only allows lookup of a fully specified domain name. 
As a consequence, programs that depend on abbreviations may not work correctly out- 
side the environment in which they were built. We can summarize: 

The domain name system only maps full domain names into ad- 
dresses; abbreviations are not part of the domain name system itself, 
but are introduced by client software to make local names convenient 
for users. 

20.17 Inverse Mappings 

We said that the domain name system can provide mappings other than machine 
name to IP address. Inverse queries allow the client to ask a server to map "back- 
wards" by taking an answer and generating the question that would produce that 
answer. Of course, not all answers have a unique question. Even when they do, a 
server may not be able to provide it. Although inverse queries have been part of the 
domain system since it was first specified, they are generally not used because there is 
often no way to find the server that can resolve the query without searching the entire 
set of servers. 


20.18 Pointer Queries 

One form of inverse mapping is so obviously needed that the domain system sup- 
ports a special domain and a special form of question called a pointer query to answer 
it. In a pointer query, the question presented to a domain name server specifies an IP 
address encoded as a printable string in the form of a domain name (i.e., a textual 
representation of digits separated by periods). A pointer query requests the name server 
to return the correct domain name for the machine with the specified IP address. 
Pointer queries are especially useful for diskless machines because they allow the sys- 
tem to obtain a high-level name given only an IP address. (We have already seen in 
Chapter 6 how a diskless machine can obtain its IP address.) 

Pointer queries are not difficult to generate. If we think of an IP address written in 
dotted-decimal form, it has the following format: 

aaa . bbb . ccc . ddd 

To form a pointer query, the client rearranges the dotted decimal representation of the 
address into a string of the form: 


ddd . ccc . bbb . aaa . in-addr . arpa 


The Domain Name System Chap 20 

The new form is a name in the special in-addr .arpa domainf. Because the local name 
server may not be the authority for either the arpa domain or the in-addr .arpa domain 
it may need to contact other name servers to complete the resolution. To make the 
resolution of pointer queries efficient, the Internet root domain servers maintain a data- 
base of valid IP addresses along with information about domain name servers that can 
resolve each address. 


20.19 Object Types And Resource Record Contents 

We have mentioned that the domain name system can be used for translating a 
domain name to a mail exchanger address as well as for translating a host name to an IP 
address. The domain system is quite general in that it can be used for arbitrary 
hierarchical names. For example, one might decide to store the names of available 
computational services along with a mapping from each name to the telephone number 
to call to find out about the corresponding service. Or one might store names of proto- 
col products along with a mapping to the names and addresses of vendors that offer 
such products. 

Recall that the system accommodates a variety of mappings by including a type in 
each resource record. When sending a request, a client must specify the type in its 
queryf; servers specify the data type in all resource records they return. The type deter- 
mines the contents of the resource record according to the table in Figure 20.9 


Type 


Meaning 


A Host Address 

CNAME Canonical Name 
CPU & OS 
Mailbox info 
Mail Exchanger 


Contents 


HINFO 
MINFO 
MX 


NS Name Server 

PTR Pointer 

SOA Start of Authority 


Arbitrary text 


32-bit IP address 

Canonical Domain Name for an alias 
Name of CPU and Operating System 
Information about a mailbox or mail list 
16-bit preference and name of host that 
acts as mail exchanger for the domain 
Name of authoritative server for domain 
Domain name (like a symbolic link) 
Multiple fields that specify which 
parts of the naming hierarchy 
a server implements 
Uninterpreted string of ASCII text 


Figure 20.9 Domain Name System resource record types. 

Most data is of type A, meaning that it consists of the name of a host attached to the In- 
ternet along with the host's IP address. The second most useful domain type MX is - 
assigned to names used for electronic mail exchangers. It allows a site to specify multi- 
ple machines that are each capable of accepting mail. When sending electronic mail 
the user specifies an electronic mail address in the form user@domain-part. The mail 

tThe octets of the IP address must be reversed when forming a domain name because IP addresses have 
the most S1 gnificant octets first while domain names have the least-significant octets first 

tQuenes can specify a few additional types (e.g., there is a query type that requests all resource recoi 
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system uses the domain name system to resolve domain-part with query type MX. The 
domain system returns a set of resource records that each contain a preference field and 
a host's domain name. The mail system steps through the set from highest preference 
to lowest (lower numbers mean higher preference). For each MX resource record, the 
mailer extracts the domain name and uses a type A query to resolve that name to an IP 
address. It tries to contact the host and deliver mail. If the host is unavailable, the 
mailer will continue trying other hosts on the list. 

To make lookup efficient, a server always returns additional bindings that it knows 
in the ADDITIONAL INFORMATION SECTION of a response. In the case of MX 
records, a domain server can use the ADDITIONAL INFORMATION SECTION to return 
type A resource records for domain names reported in the ANSWER SECTION. Doing 
so substantially reduces the number of queries a mailer sends to its domain server. 

20.20 Obtaining Authority For A Subdomain 

Before an institution is granted authority for an official second-level domain, it 
must agree to operate a domain name server that meets Internet standards. Of course, a 
domain name server must obey the protocol standards that specify message formats and 
the rules for responding to requests. The server must also know the addresses of 
servers that handle each subdomain (if any exist) as well as the address of at least one 
root server. 

In practice, the domain system is much more complex than we have outlined. In 
most cases, a single physical server may handle more than one part of the naming 
hierarchy. For example, a single name server at Purdue University handles both the 
second-level domain purdue . edu as well as the geographic domain laf. in . us. A sub- 
tree of names managed by a given name server forms a zone of authority. Another 
practical complication arises because servers must be able to handle many requests, 
even though some requests take a long time to resolve. Usually, servers support con- 
current activity, allowing work to proceed on later requests while earlier ones are being 
processed. Handling requests concurrently is especially important when the server re- 
ceives a recursive request that forces it to send the request on to another server for reso- 
lution. 

Server implementation is also complicated because the Internet authority requires 
that the information in every domain name server be replicated. Information must ap- 
pear in at least two servers that do not operate on the same computer. In practice, the 
requirements are quite stringent: the servers must have no single common point, of 
failure. Avoiding common points of failure means that the two name servers cannot 
both attach to the same network; they cannot even obtain electrical power from the 
same source. Thus, to meet the requirements, a site must find at least one other site that 
agrees to operate a backup name server. Of course, at any point in the tree of servers, a 
server must know how to locate both the primary and backup name servers for sub- 
domains, and it must direct queries to a backup name server if the primary server is 
unavailable. 
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1. Introduction 

This memo is an introductory guide to some of the TCP/IP and Internet 
tools and utilities that allow users to access the wide variety of 
information on the network, from determining if a particular host is 
up to viewing a multimedia thesis on foreign policy. It also 
describes discussion lists accessible from the Internet, ways to 
obtain Internet documents, and resources that help users weave their 
way through the Internet. This memo may be used as a tutorial for 
individual self -learning, a step-by- step laboratory manual for a 
course, or as the basis for a site's users manual. It is intended as 
a basic guide only and will refer to other sources for more detailed 
information. 

2. A Beginner's Guide to TCP/IP-based Utilities and Applications 

This section provides descriptions and detailed examples of several 
TCP/IP utilities and applications, including actual sessions using 
these utilities (with some extraneous information removed) . Each 
section below describes a single TCP/IP-based tool, it's application, 
and, in some cases, how it works. The text description is followed 
by an actual sample session. 

The sample dialogues shown below were made using the Multinet TCP/IP 
software for VAX/VMS or DOS versions of FTP Software's PC/TCP. While 
the examples below can be used as a guide to using and learning about 
the capabilities of these tools, the reader should understand that 
not all of these utilities may be found at all TCP/IP hosts nor in 
all commercial software packages. Furthermore, the user interface 
for different packages will be different and the actual command line 
may appear differently than shown here,- this will be particularly 
true for graphical user interfaces running over Windows, X-Windows, 
OS/2, or Macintosh systems. The Internet has many exciting things to 
offer but standardized interfaces to the protocols is not yet one of 
them! This guide will not provide any detail or motivation about the 
Internet Protocol Suite; more information about the TCP/IP protocols 
and related issues may be found in RFC 1180 [18] , Comer [22] , Feit 
[23] , and Kessler [30] . 

In the commands shown in the descriptions below, any item appearing 
in square brackets ( [] ) is optional and the vertical-bar (|) means 
"or" ; parameters appearing with no brackets or within curly brackets 
({}) are mandatory. In the sample dialogues, most user input is in 
capital letters (only where allowed) and lines containing user input 
are designated with a "**" in the far-left margin. 

AUTHOR'S NOTE: The sample dialogues are easier to read in the 
secondary, Postscript version of this RFC. 
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2.1. NSLOOKUP 


NSLOOKUP is the name server lookup program that comes with many 
TCP/IP software packages. A user can use NSLOOKUP to examine entries 
in the Domain Name System (DNS) database that pertain to a particular 
host or domain; one common use is to determine a host system's IP 
address from its name or the host's name from its IP address. The 
general form of the command to make a single query is : 

NSLOOKUP [IP_address | host_name] 

If the program is started without any parameters, the user will be 
prompted for input; the user can enter either an IP address or host 
name at that time, and the program will respond with the name and 
address of the default name sever, the name server actually used to 
resolve each request, and the IP address and host name that was 
queried. "Exit" is used to quit the NSLOOKUP application. 

Three simple queries are shown in the example below: 

1. Requests the address of the host named "emily.uvm.edu", a system at 
the University of Vermont (UVM) . As it turns out, this is not the 
true name of the host, but a shortened version of the name that is 
accepted as an alias by the network. The full name of the host and 
the IP address are listed by NSLOOKUP. 

2. Requests the address of host "emily.emba.uvm.edu", which is the 
same host as in the first query. Note that NSLOOKUP provides a 
"non-authoritative" answer. Since NSLOOKUP just queried this same 
address, the information is still in its cache memory. Rather than 
send additional messages to the name server, the answer is one that 
it remembers from before; the server didn't look up the information 
again, however, so it is not guaranteed to still be accurate 
(because the information might have changed within the last few 
milliseconds!). 

3. Requests the name of the host with the given IP address. The 
result points to the Internet gateway to Australia, 
"munnari.oz.au" . 

One additional query is shown in the dialogue below. NSLOOKUP 
examines information that is stored by the DNS. The default NSLOOKUP 
queries examine basic address records (called "A records") to 
reconcile the host name and IP address, although other information is 
also available. In the final query below, for example, the user 
wants to know where electronic mail addressed to the "uvm.edu" domain 
actually gets delivered, since "uvm.edu" is not the name of an actual 
host. This is accomplished by changing the query type to look for 
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mail exchange (MX) records by issuing a "set type" command (which 
must be in lower case) . The query shows that mail addressed to 
"uvm.edu" is handled though a mail server called "moose.uvm.edu". The 
DNS is beyond the scope of this introduction, although more 
information about the concepts and structure of the DNS can be found 
in STD 13/RFC 1034 [12] and RFC 1591 [13] . The "help" command can be 
issued at the program prompt for information about NSLOOKUP ' s more 
advanced commands . 

TECHNICAL NOTE: There are other tools that might be available on your 
system or with your software for examining the DNS. Alternatives to 
NSLOOKUP include HOST and DIG. 


■ SMCVAX$ NSLOOKUP 

Default Server: LOCALHOST 
Address: 127.0.0.1 

' > EMILY.UVM.EDU 
Server : LOCALHOST 
Address: 127.0.0.1 

Name : emi ly . emba . uvm . edu 
Address: 132.198.1.7 
Aliases: emily.uvm.edu 

■ > EMILY.EMBA.UVM.EDU 
Server : LOCALHOST 
Address: 127.0.0.1 

Non- authoritative answer: 
Name : emi ly . emba . uvm . edu 
Address: 132.198.1.7 

' > 128.250.1.21 
Server : LOCALHOST 
Address: 127.0.0.1 

Name : munnari . OZ . AU 
Address: 128.250.1.21 

■ > set type=MX 
' > UVM.EDU 

Server : LOCALHOST 
Address: 127.0.0.1 

uvm.edu preference = 10, mail exchanger = moose.' 
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moose.uvm.edu internet address = 132.198.101.60 
** > EXIT 
SMC VAX $ 


2.2. PING 

Ping is one of the most widely available tools bundled with TCP/IP 
software packages. Ping uses a series of Internet Control Message 
Protocol (ICMP) Echo messages to determine if a remote host is active 
or inactive, and to determine the round- trip delay in communicating 
with it. The Ping command, referred to as the Packet Internetwork 
Groper in some references, has the following general format: 

PING t-s] {lP_address | host_name} [size], [quantity] 

In the first test below, we ping the host "thumper.bellcore.com" to 
determine whether it is up and running. This simple use of the 
command contains no optional parameters. 

In the second test, the "-s" parameter tells the system to send an 
ICMP Echo message every second. The optional "size" parameter 
specifies that each message should be 64 bytes in length (which is 
the default size) ; the optional "quantity" parameter indicates that 
this test will only send 12 messages (the default is to run the test 
continuously until interrupted) . The results of the second test 
displays the round-trip delay of each Echo message that is returned 
to the sending host; at the end of the test, summary statistics are 
displayed . 


** SMCVAX$ PING THUMPER.BELLC0RE.COM 
thumper.bellcore.com is alive 


** SMCVAX$ PING -S THUMPER.BELLC0RE.COM 64 12 

PING THUMPER.BELLC0RE.COM (12 8.96.41.1): 56 data bytes 


64 

bytes 

from 

128 

. 96 

.41. 

.1: 

icmp_ 

_seq=0 

time=150 

ms 

64 

bytes 


128 

. 96 

.41. 

. 1 : 

icmp_ 

_seq=l 

time=110 

ms 

64 

bytes 

from 

128 

. 96 

.41 , 

. 1 : 

icmp_ 

_seq=2 

time=130 


64 

bytes 

from 

128 

. 96 

.41 , 

. 1 : 

icmp_ 

_seq=3 

time=130 

ms 

64 

bytes 

from 

128 

. 96 

.41 , 

. 1 : 

icmp_ 

_seq=4 

time=320 

ms 

64 

bytes 

from 

128 

.96 

.41 , 

.1: 

icmp_ 

_seq=5 

time=110 

ms 

64 

bytes 

from 

128 

.96 

.41 , 

. 1 : 

icmp_ 

_seq=6 

time=440 


64 

bytes 

from 

128 

. 96 

.41 . 

. 1 : 

icmp_ 

_seq=7 

time=90 ms 

64 

bytes 

from 

128 

.96 

.41 . 

. 1 : 

icmp_ 

_seq=9 

time=100 

ms 

64 

bytes 

from 

128 

.96 

.41 , 

. 1 : 

icmp_ 

_seq=10 time=110 ms 
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THUMPER.BELLC0RE.COM PING Statistics 


12 packets transmitted, 10 packets received, 16% packet loss 
round-trip (ms) min/avg/max = 90/169/440 


SMCVAX$ 


3 . FINGER 

The Finger program may be used to find out who is logged in on 
another system or to find out detailed information about a specific 
user. This command has also introduced a brand new verb; "fingering" 
someone on the Internet is not necessarily a rude thing to do! The 
Finger User Information Protocol is described in RFC 1288 [20] . The 
most general format of the Finger command is: 

FINGER [username] @host_name 

The first example below shows the result of fingering an individual 
user at a remote system. The first line of the response shows the 
username, the user's real name, their process identifier, 
application, and terminal port number. Additional information may be 
supplied at the option of the user in "plan" and/or "project" files 
that they supply,- these files are often named PLAN. TXT or 
PROJECT . TXT, respectively, and reside in a user's root directory (or 
somewhere in an appropriate search path) . 

The second example shows the result of fingering a remote system. 
This lists all of the processes currently running at the fingered 
system or other information, depending upon how the remote system's 
administrator set up the system to respond to the Finger command. 
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* * C : \ > FINGER KUMQUATOSMCVAX . SMCVT . EDU 


[smcvax. smcvt . edu] 

KUMQUAT Gary Kessler 20A02991 MAIL TXA3 

Last login Fri 15 -Jul-1994 2:59 PM-EDT 

Plan: 


Gary C. Kessler 

Adjunct Faculty Member, Graduate College 
Senior Member of Technical Staff 

Hill Associates +1 802-655-8633 or 655-0940 (office) 

17 Roosevelt Highway +1 802-655-7974 (fax) 

Colchester, VT 05446 +1 802-879-5242 (home) 

INTERNET: kumquat@smcvax.smcvt.edu or kumquat@hill.com 


C:\> FINGER ©SMCVAX . SMCVT . EDU 
[ smcvax . smcvt .edu] 

Friday, July 15, 1994 4:00PM-EDT Up 21 03:41:31 
7+0 Jobs on SMCVAX Load ave 0.24 0.31 0.25 


User 

Personal Name 

Subsys 

DENIS 

Denis Stratford 

MAIL 

GOODWIN 

Dave Goodwin 

RTPAD 

JAT 

John Trono 

EDT 

KUMQUAT 

Gary Kessler 

MAIL 

INFO 

SMC Info Service 

TELNET 

SYSTEM 

System Manager 

*DCL* 

SMITH 

Jim Smith 

LYNX 

C:\> 




4 . TRACEROUTE 

Traceroute is another common TCP/IP tool, this one allowing users to 
learn about the route that packets take from their local host to a 
remote host. Although used often by network and system managers as a 
simple, yet powerful, debugging aid, traceroute can be used by end 
users to learn something about the structure of the Internet . 

The Traceroute command has the following general format (where "#" 
represents a positive integer value associated with the qualifier) : 

TRACEROUTE [-m #] [-q #] [-w #] [-p #] {lP_address | host_name} 
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where -m is the maximum allowable TTL value, measured as the 

number of hops allowed before the program terminates 
(default = 30) 


-q is the number of UDP packets that will be sent with each 

time-to-live setting (default = 3) 
-w is the amount of time, in seconds, to wait for an answer 

from a particular router before giving up (default = 5) 
-p is the invalid port address at the remote host (default = 

33434) 

The Traceroute example below shows the route between a host at St. 
Michael's College in Colchester, Vermont (smcvax.smcvt.edu) and a 
host at Bellcore in Red Bank, New Jersey (thumper.bellcore.com). The 
output has some interesting points: 

1. NEARnet, the New England Academic and Research Network, is a 
regional network serving the northeastern U.S. The packets' route 
runs from St. Mike's NEARnet gateway (smc-gw) to the University of 
Vermont (uvm-gw) , etc. Note that some intermediate systems (see 
lines 4 and 16) do not have names associated with them. 

2. From NEARnet (lines 1-6), the packets travel on the National 
Science Foundation Network (NSFNET) T3 backbone (lines 7-11) . The 
NSFNET backbone nodes are identified as "ans.net" since the NSFNET 
is operated by Advanced Networks and Services, Inc. (ANS) . The 
packets travel within ANS' network on their core nodal switching 
subsystems ("cnss") until ready to jump off the backbone; line 11 
indicates an ANS exterior nodal switching subsystem ("enss"). The 
datagrams are then carried on the JvNCnet (lines 12-16) , a regional 
network in New Jersey (note the use of SMDS ! ) . Finally, the 
datagrams are placed on Bellcore's internal network (lines 17 and 
18) for final delivery. 

3. Note that not all of the datagrams take the same route. In 
particular, only two of the datagrams go through the ANS gateway 
referred to at line 10. Note also line 17; here, the first two 
datagrams go through one router at Bellcore, while the third 
datagram goes through a companion router. 

TECHNICAL NOTE: Traceroute works by sending a sequence of User 
Datagram Protocol (UDP) datagrams to an invalid port address at the 
remote host. Using the default settings, three datagrams are sent, 
each with a Time-To-Live (TTL) field value set to one. The TTL value 
of 1 causes the datagram to "timeout" as soon as it hits the first 
router in the path; this router will then respond with an ICMP Time 
Exceeded Message (TEM) indicating that the datagram has expired. 
Another three UDP messages are now sent, each with the TTL value set 
to 2, which causes the second router to return ICMP TEMs . This 
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process continues until the packets actually reach the other 
destination. Since these datagrams are trying to access an invalid 
port at the destination host, ICMP Destination Unreachable Messages 
are returned indicating an unreachable port; this event signals the 


Traceroute program that it is finished! The Traceroute program 
displays the round-trip delay associated with each of the attempts. 

As an interesting aside, Traceroute did not begin life as a general- 
purpose utility, but as a quick-and-dirty debugging aid used to find 
a routing problem. The code (complete with comments!) is available 
by anonymous FTP in the file " traceroute . tar . Z " from the host 
"ftp.ee.lbl.gov". (See Section 2.5 for a discussion of anonymous 
FTP. ) 


SMCVAX$ TRACEROUTE THUMPER.BELLC0RE.COM 

traceroute to THUMPER.BELLC0RE.COM (128.96.41.1), 30 hops max, 38 
byte packets 

1 smc-gw.near.net (192.80.64.5) 50 ms 20 ms 10 ms 

2 uvm-gw.near.net (131.192.152.1) 160 ms 50 ms 30 ms 

3 harvard-gw.near.net (131.192.65.1) 470 ms 60 ms 60 ms 

4 131.192.32.3 (131.192.32.3) 50 ms 50 ms 40 ms 

5 mit2-gw.near.net (131.192.7.1) 50 ms 40 ms 40 ms 

6 enss.near.net (192.54.222.6) 60 ms 90 ms 40 ms 

7 t3-2.Hartford-cnss49.t3.ans.net (140.222.49.3) 70 ms 100 ms 60 ms 

8 t3-3.Hartford-cnss48.t3.ans.net (140.222.48.4) 70 ms 40 ms 40 ms 

9 t3-2.New-York-cnss32.t3.ans.net (140.222.32.3) 50 ms 60 ms 70 ms 

10 * t3-0.New-York-cnss3 3.t3.ans.net (140.222.33.1) 340 ms 110 ms 

11 t3-0.enssl37.t3.ans.net (140.222.137.1) 90 ms 420 ms 190 ms . 

12 zaphod-gateway.jvnc.net "(192.12.211.65) 70 ms 50 ms 70 ms 

13 airportl-gateway.jvnc.net (130.94.6.250) 390 ms 110 ms 60 ms 

14 airport4-gateway.jvnc.net (130.94.7.4) 70 ms 50 ms 60 ms 

15 coreSMDS-gateway.jvnc.net (130.94.7.106) 80 ms 130 ms 100 ms 

16 128.96.58.2 (12 8.96.58.2) 80 ms 70 ms 100 ms 

17 lab214b-cisco.cc.bellcore.com (128.96.34.40) 120 ms 120 ms 
lab214-cisco.cc.bellcore.com (128.96.34.101) 130 ms 

18 thumper.bellcore.com (128.96.41.1) 130 ms 430 ms 80 ms 

SMCVAX$ 
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2.5. FTP 

The File Transfer Protocol (FTP) [16] is one of the most useful and 
powerful TCP/IP utilities for the general user. FTP allows users to 
upload and download files between local and remote hosts . Anonymous 


FTP, in particular, is commonly available at file archive sites to 
allow users to access files without having to pre-establish an 
account at the remote host. The general form of the FTP command is: 

FTP [IP_address | host_name] 

As shown, FTP can be initiated in several ways. In the example shown 
below, an FTP control connection is initiated to a host by supplying 
a host name with the FTP command; optionally, the host's IP address 
in dotted decimal form could be used. If neither host name nor IP 
address are supplied in the command line, a connection to a host can 
be initiated by typing "OPEN host_name" or "OPEN IP_address" once the 
FTP application has been started. 

The remote host will now ask for a username and password. If a 
legitimate, registered user of this host supplies a valid username 
and password, then the user will have access to any files and 
directories to which this username has privilege. For anonymous FTP 
access, the username "anonymous" is used and the password (not shown 
in actual use) is "guest" (although an increasing number of systems 
ask that anonymous FTP users supply their Internet address as the 
password) . 

The first command issued in the example below is "help ?", used to 
obtain a list of available FTP commands and help topics. Although 
not always shown, nearly all TCP/IP applications have a help command. 

An example of the help for FTP'S "type" command is shown in the 
sample dialogue. This command is very important one, by the way; if 
transferring a binary or executable file, be sure to set the type to 
"image" (or "binary" on some systems) . 

The "dir" command provides a directory listing of the files in the 
current directory at the remote host; the UNIX "Is" command may also 
usually be used. Note that an FTP data transfer connection is 
established for the transfer of the directory information to the 
local host. The output from the "dir" command will show a file 
listing that is consistent with the native operating system of the 
remote host. Although the TCP/IP suite is often associated with 
UNIX, it can (and does) run with nearly all common operating systems. 

The directory information shown in the sample dialogue happens to be 
in UNIX format and includes the following information: 
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o File attributes. The first character identifies this as a 

directory (d) , link (1), or individual file (-). The next nine 
characters list the access permissions for three groups, namely, 
the owner, the owner's group, and all other users. Three access 
privileges may be assigned to each file for each of these groups: 
read (r) , write (w) , execute (x) , and/or search (s) . 


o File owner and owner's group. 


o File size, in bytes. 

o Date of last modification. If the date is followed by a timestamp, 
then the date is from the current year. 

o File name. 

After the directory information has been transferred, FTP closes the 
data transfer connection. 

The command "cd" is used to change to another directory, in this case 
the "Gov" directory (note that file and directory names may be case- 
sensitive) . As in DOS, "cd .." will change to the parent of the 
current directory. The "CWD command successful" is the only 
indication that the user's "cd" command was correctly executed; the 
"show-directory" (may be truncated to fewer characters, as shown) 
command, if available, may be used to see which directory you are in. 

Another "dir" command is used to find all files ending with the 
characters ".act"; note the use of the "*" wildcard character. We 
can now copy (download) the file of choice (The Fair Credit Reporting 
Act, 1992) by using the "get" (or "receive") command, which has the 
following general format: 

GET remote_f ile_name local_f ile_name 

FTP opens another data transfer connection for this file transfer 
purpose; note that the effective data transfer rate is 3 9.98 kbps . 

FTP'S "put" (or "send") command allows uploading from the local host 
to the remote. "Put" is often not available when using anonymous 
FTP. 

Finally, we terminate the FTP connection by using the "close" 
command. The user can initiate another FTP connection using the 
"open" command or can leave FTP by issuing a "quit" command. "Quit" 
can also be used to close a connection and terminate a session. 
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TECHNICAL NOTE: It is important to note that different FTP packages 
have different commands available and even those with similar names 
may act differently. In the example shown here (using MultiNet for 
VMS) , the "show" command will display the current directory; in 
another package (e.g., FTP Software's PC/TCP), "show" will display a 
file from the remote host at the local host. Some packages have 
nothing equivalent to either of these commands ! 


** SMCVAX$ FTP FTP.SPIES.COM 

SMCVAX.SMCVT.EDU MultiNet FTP user process 3.2(106) 
Connection opened (Assuming 8 -bit connections) 

** User name: ANONYMOUS 

** Password: GUEST 

** WIRETAP. SPIES. C0M> HELP ? 

Commands may be one of the following: 


ACCOUNT AGET 

APPEND APUT 

ASCII ATTACH 

BELL BINARY 

BYE BYTE 

CD CDUP 

CLOSE CONFIRM 

CPATH CREATE -DIRECTORY 

CWD DELETE 

DIRECTORY DISCONNECT 

EXIT EXIT-ON-ERROR 

GET HASH 

HELP LCD 

LDIR LOCAL -CD 

LOCAL-DIRECTORY LOCAL-PWD 

LOGIN LPWD 

LS MDELETE 

MGET MKDIR 

MODE MPUT 

MULTIPLE PASSWORD 

PORT PROMPT - FOR - MI S S ING -ARGUMENTS 

PROMPT-ON-CONNECT PUSH 

PUT PWD 

QUIT QUOTE 

RECEIVE REMOTE-HELP 

REMOVE-DIRECTORY RENAME 

RETAIN RM 

RMDIR SEND 

SHOW -DIRECTORY SITE 

SPAWN STATISTICS 

STATUS STREAM 
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STRUCTURE TAKE 

TENEX TYPE 

USER VERBOSE 
VERSION 


** WIRETAP. SPIES. C0M> HELP TYPE 

The TYPE command changes the FTP transfer type. The possible 
arguments to the TYPE command are ASCII, IMAGE, BACKUP, and 


LOGICAL -BYTE ASCII type is used for transferring ASCII text files. 
IMAGE type is used for transferring binary files. BACKUP type is 
used for transferring VAX/VMS backup savesets with 2048 byte block 
size . 

** WIRETAP. SPIES. COM> DIR 

<Opening ASCII mode data connection for /bin/Is. 
total 25 


drwxr-xr-x 

2 

9013 

aemon 


U , 




drwxr-xr-x 

4 

9013 


512 

U 


1993 

Ab^t 

-rw-r- -r- - 

1 

9013 

daemon 
aemon 

791' 



1993 

About Go her 
ou _ op er 

drwxr-xr-x 

3 

9013 

aemon 


J P 1 

12 

1993 


drwxr-xr-x 

13 

9013 


512 

Jul 


1993 

Clinton 

lrwxrwxrwx 

1 

root 

daemon 
aemon 

12 

Feb 

26 

07 • 02 

Economic Plan 
conomic_ a 

-> Gov/Economic 







drwxr-xr-x 

4 

9013 

daemon 

512 

Jul 


1993 

Etext 

lrwxrwxrwx 

1 

root 

daemon 

13 

Feb 

26 

07-01 

GAQ X Re orts 
_ epor s 

Gov/GAO- Trans 








drwxr-xr-x 

29 

9013 

daemon 

1024 

Feb 

3 

00 • 15 

Gov 

drwxr-xr-x 

16 

9013 

daemon 

512 

Jul 

1 

1993 

Library 

lrwxrwxrwx 

1 

root 

daemon 

9 

Feb 

26 

06:56 

NAFTA -> 

Gov/NAFTA 









drwxr-xr-x 

2 

9013 

daemon 

512 

Jul 

1 

1993 

Other 

drwxr-xr-x 

3 

9013 

daemon 

3072 

Apr 

7 

20:59 

alt. etext 

drwxr-xr-x 

8 

root 

42 

512 

Jul 

1 

1993 

ba . internet 

dr-xr-xr-x 

2 

bin 

wheel 

512 

Jul 

1 

1993 

bin 

drwxr-xr-x 

2 

root 

daemon 

512 

Feb 

15 

06 : 14 

dev 

drwxr-xr-x 

3 

root 

wheel 

512 

Jul 

1 

1993 

etc 

drwxr-xr-x 

11 

9038 

daemon 

512 

Dec 

17 

05 :37 

game_ar chive 

drwx-wx-wx 

3 

root 

daemon 

1024 

Apr 

18 

02 : 09 

incoming 

drwxr-xr-x 

3 

root 

ftp 

512 

Oct 

29 

02 :35 

pub 

drwxr-xr-x 

2 

root 

daemon 

512 

Jul 

1 

1992 

tmp 

drwxr-xr-x 

3 

root 

daemon 

512 

Jul 

1 

1993 

usr 

drwxr-xr-x 

3 

9013 

42 

1024 

Jul 

1 

1993 

waffle 


<Transfer complete. 

1490 bytes transferred at 4966 bps. 

Run time = 10. ms, Elapsed time = 2400. ms. 

WIRETAP. SPIES. COM> CD Gov 
<CWD command successful. 
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** WIRETAP. SPIES. C0M> SHOW 

<"/Gov" is current directory. 

** WIRETAP. SPIES. COM> DIR * . act 

<Opening ASCII mode data connection for /bin/Is. 


-rw-r--r-- 1 9013 42 32695 Dec 10 21:37 brady.act 

-r--r--r-- 1 9013 42 168649 Mar 26 1993 disable. act 

-r--r--r-- 1 9013 42 62602 Mar 30 1993 ecpa.act 

-r--r--r-- 1 9013 42 29519 Mar 30 1993 f aircredit . act 


-r--r--r-- 1 9013 42 
-r--r--r-- 1 9013 42 
<Transfer complete. 
401 bytes transferred at 7638 bp 
Run time = 0. ms, Elapsed time = 


57206 Mar 30 1993 privacy. act 

16261 Mar 26 1993 warpower . act 

s . 

420. ms. 


WIRETAP. SPIES. C0M> GET f aircredit . act FAIRCRDT.TXT 

<Opening ASCII mode data connection for f aircredit . act (29519 

bytes) . 

<Transfer complete. 

30132 bytes transferred at 39976 bps. 

Run time = 40. ms , Elapsed time = 6030. ms . 


** WIRETAP. SPIES. C0M> QUIT 
<Goodbye . 
SMCVAX$ 


2.6. TELNET 

TELNET [17] is TCP/IP ' s virtual terminal protocol. Using TELNET, a 
user connected to one host can login to another host, appearing like 
a directly-attached terminal at the remote system; this is TCP/IP's 
definition of a "virtual terminal." The general form of the TELNET 
command is: 

TELNET [IP_address | host_name] [port] 

As shown, a TELNET connection is initiated when the user enters the 
"TELNET" command and supplies either a "host_name" or "IP_address" ; 
if neither are given, TELNET will ask for one once the application 
begins . 

In the example below, a user logged onto a PC on a LAN will use 
TELNET to attach to the remote host "smcvax.smcvt.edu". Once logged 
in via TELNET, the user can do anything on the remote host that they 
could do if they were on a directly-connected terminal or had dialed- 
up by modem. The commands that are used are those available on the 
remote system to which the user is attached. In the sample dialogue 
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below, the user attached to SMCVAX will use basic VAX/VMS commands: 

o The "dir" command lists the files having a "COM" file extension, 
o The "mail" command enters the MAIL system (there are no messages) . 
o "Pinging" the home host shows that it is alive! 

When finished, "logout" logs the user off the remote host; TELNET 
automatically closes the connection to the remote host and returns 
control to the local system. 


It is important to note that TELNET is a very powerful tool, one that 
may provide users with access to many Internet utilities and services 
that might not be otherwise available. Many of these features are 
accessed by specifying a port number with the TELNET command, in 
addition to a host's address, and knowledge of port numbers provides 
another mechanism for users to access information with Telnet. 

This guide discusses several TCP/IP and Internet utilities that 
require local client software, such as Finger, Whois, Archie, and 
Gopher. But what if your software does not include a needed client? 
In some cases, Telnet may be used to access a remote client and 
provide the same functionality. 

This is done by specifying a port number with the TELNET command. 
Just as TCP/IP hosts have a unique IP address, applications on the 
host are associated with an address, called a "port". Finger, for 
example, is associated with the well-known port number 79. In the 
absence of a Finger client, TELNETing to port 79 at a remote host may 
provide the same information. You can "finger" another host with 
TELNET by using a command like: 

TELNET host_name 7 9 

Other well-known TCP/IP port numbers include 20 (FTP data transfer) , 
21 (FTP control), 25 (SMTP), 43 (whois), 70 (Gopher), and 185 
(KNOWBOT) . 

Some services are available on the Internet using TELNET and special 
port numbers. A geographical information database, for example, may 
be accessed by TELNETing to port 3000 at host 

"martini.eecs.umich.edu"; current weather information is available at 
port 3 00 0 at hosts "downwind.sprl.umich.edu" and 
"wind.atmos.uah.edu". 
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** C:\> TELNET SMCVAX.SMCVT.EDU 

FTP Software PC/TCP tn 2.31 01/07/94 12:38 

Copyright (c) 1986-1993 by FTP Software, Inc. All rights reserved 

- Connected to St. Michael's College - 

** Username: KUMQUAT 
** Password: 

St. Michael's College VAX/VMS System. 


Node SMCVAX. 


Last interactive login on Thursday, 9-JUN-1994 11:55 
Last non-interactive login on Thursday, 9-JUN-1994 08:20 

Good Afternoon User KUMQUAT. Logged in on 12-JUN-1994 at 3:27 PM . 

User [GUEST, KUMQUAT] has 4292 blocks used, 5708 available, 

of 10000 authorized and permitted overdraft of 100 blocks on $1$DIA2 

SMCVAX$ DIR *.C0M 

Directory $1$DIA2 : [GUEST . KUMQUAT] 


BACKUP. COM; 24 

24 

16- 

-JUL- 

-1990 

16 

:22 : 

;46 

.68 

(RWED, 

, RWED , 

RE, ) 

DELTREE.COM; 17 

3 

16- 

-JUL- 

-1990 

16 

:22 : 

:47 

.58 

(RWED, 

, RWED , 

. RE , ) 

EXPANDZ.COM; 7 

2 

22- 

-FEB- 

-1993 

10 

:00: 

: 04 

.35 

(RWED, 

, RWED , 

■RE, ) 

FTSLOGBLD.COM; 3 

1 

16- 

-JUL- 

-1990 

16 

:22 : 

:48 

.57 

(RWED, 

, RWED , 

RE, ) 

FTSRRR.COM; 2 

1 

16- 

-JUL- 

-1990 

16 

:22 : 

:48 

.73 

(RWED, 

, RWED , 

■RE, ) 

LOGIN. COM; 116 

5 

1- 

-DEC- 

-1993 

09 

:33 : 

:21 

.61 

(RWED, 

, RWED , 

RE, ) 

SNOOPY. COM; 6 

1 

16- 

-JUL- 

-1990 

16 

:22 : 

:52 

. 06 

(RWED, 

, RWED , 

RE, ) 

SYL0GIN.COM; 83 

8 

16- 

-JUL- 

-1990 

16 

:22 : 

:52 

.88 

(RWED, 

, RWED , 

. RE , RE) 

SYSHUTDWN . COM ; 1 

0 

16- 

-JUL- 

-1990 

16 

:22 

:53 

. 04 

(RWED, 

, RWED , 

.RE, ) 

SYSTARTUP.COM; 8 8 

15 

16- 

-JUL- 

-1990 

16 

:22 

:53 

.21 

(RWED, 

, RWED , 

RE, ) 

WATCH_MAIL.C0M;1 

173 

10- 

-MAY- 

-1994 

09 

:59 

:52 

.65 

(RWED, 

, RWED , 

RE, ) 


Total of 11 files, 233 blocks. 

** SMCVAX$ MAIL 
** MAIL> EXIT 

** SMCVAX$ PING HILL.COM /N=5 

PING HILL.COM (19 9.182.20.4): 56 data bytes 

64 bytes from 199.182.20.4: icmp_seq=0 time=290 ms 

64 bytes from 199.182.20.4: icmp_seq=l time=260 ms 

64 bytes from 199.182.20.4: icmp_seq=2 time=260 ms 

64 bytes from 199.182.20.4: icmp_seq=3 time=260 ms 

64 bytes from 199.182.20.4: icmp_seq=4 time=260 ms 
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HILL.COM PING Statistics 

5 packets transmitted, 5 packets received, 0% packet loss 
round-trip (ms) min/avg/max = 260/266/290 

** SMCVAX$ LOGOUT 

KUMQUAT logged out at 12-JUN-1994 15:37:04.29 

Connection #0 closed 


C:\> 


2.7. User Database Lookup Tools 


2.7.1. WHOIS/NICNAME 

WHOIS and NICNAME are TCP/IP applications that search databases to 
find the name of network and system administrators, RFC authors, 
system and network points-of -contact , and other individuals who are 
registered in appropriate databases. The original NICNAME/WHOIS 
protocol is described in RFC 954 [4] . 

WHOIS may be accessed by TELNETing to an appropriate WHOIS server and 
logging in as "WHOIS" (no password is required) ; the most common 
Internet name server is located at the Internet Network Information 
Center (InterNIC) at "rs.internic.net". This specific database, in 
particular, only contains INTERNET domains, IP network numbers, and 
points of contact; policies governing the InterNIC database are 
described in RFC 1400 [19] . The MILNET database resides at 
"nic.ddn.mil" and PSI's White Pages pilot service is located at 
"psi . com" . 

Many software packages contain a WHOIS/NICNAME client that 
automatically establishes the TELNET connection to a default name 
server database, although users can usually specify any name server 
database that they want . 

The accompanying dialogues shows several types of WHOIS/NICNAME 
information queries. In the session below, we request information 
about an individual (Denis Stratford) by using WHOIS locally, a 
specific domain (hill.com) by using NICNAME locally, and a high-level 
domain (edu) using TELNET to a WHOIS server. 
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SMCVAX$ WHOIS STRATFORD, DENIS 

Stratford, Denis (DS378) denis@@SMCVAX . SMCVT . EDU 

St. Michael's College 
Jemery Hall, Room 2 74 
Winooski Park 
Colchester, VT 05439 
(802) 654-2384 


Record last updated on 02 -Nov- 92. 
SMCVAX$ 


C:\> NICNAME HILL.COM 


Hill Associates (HILL-DOM) 
17 Roosevelt Highway 
Colchester, VT 05446 

Domain Name: HILL.COM 


Administrative Contact: 

Kessler, Gary C. (GK34) kumquat@HILL.COM 

(802) 655-8633 
Technical Contact, Zone Contact: 

Monaghan, Carol A. (CAM4) cam@HILL.COM 

(802) 655-8630 


Record last updated on 15-Jun-94. 
Domain servers in listed order: 


NETCOMS V . NETCOM . COM 192.100.81.101 
NS.NETC0M.COM 192.100.81.105 
C:\> TELNET RS.INTERNIC.NET 

Connected to RS.INTERNIC.NET, a SUN 670 running SUNOS-4.1.3 


-- InterNIC Registration Services Center 


Cmdinter Ver 1.3 Mon Mar 21 13:42:27 1994 EST 
** [dec-vt220] InterNIC> WHOIS 
Connected to the rs Database 

InterNIC WHOIS Version: 1.0 Mon, 21 Mar 94 13:42:32 


** Whois: DOMAIN EDU 

Education top-level domain (EDU-DOM) 
Network Solutions, Inc. 
505 Huntmar park Dr. 
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Herndon, VA 22 07 0 
Domain Name : EDU 

Administrative Contact, Technical Contact, Zone Contact: 
Network Solutions, Inc. (HOSTMASTER) HOSTMASTER@INTERNIC.NET 
(703) 742-4777 (FAX) (703) 742-4811 

Record last updated on 16 -May- 94. 

Domain servers in listed order: 


NS.INTERNIC.NET 
AOS.ARL.ARMY.MIL 


198 .41 .0.4 

128.63.4.82, 192.5.25.82 


NS1.ISI.EDU 
CNYSER.NET 
TERP . UMD . EDU 
NS . NASA . GOV 
NIC.NORDU.NET 
NS.NIC.DDN.MIL 


128.9.0.107 
192.33.4.12 
128.8.10.90 

128.102.16.10, 192.52.195.10 

192.36.148.17 

192 . 112 .36.4 


Would you like to see the known domains under this top-level domain? 
** Y 


There are 1504 known sub-domains: 


0 . EDU Reserved Domain 

1 . EDU Reserved Domain 

2. EDU Reserved Domain 
22CF.EDU 22nd Century Foundation 

3. EDU Reserved Domain 
There are 1499 more matches. Show them? N 


** Whois: EXIT 


** [dec-vt220] InterNIC> QUIT 


Connection #0 closed 
C:\> 
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2.7.2. KNOWBOT 

KNOWBOT is an automated username database search tool that is related 
to WHOIS. The Knowbot Information Service (KIS) provides a simple 
WHOIS-like interface that allows users to query several Internet user 
databases (White Pages services) all at one time. A single KIS query 
will automatically search the InterNIC, MILNET, MCImail, and PSI 
White Pages Pilot Project; other databases may also be included. 

KNOWBOT may be accessed by TELNETing to port 185 at host 
"info. cnri . reston . va . us " or "sol.bucknell.edu". The "help" command 
will supply sufficient information to get started. The sample 
dialogue below shows use of the "query" command to locate a user 
named "Gary Kessler"; this command automatically starts a search 
through the default set of Internet databases . 


■* C:\> TELNET INFO . CNRI . RESTON . VA . US 185 


Knowbot Information Service 
KIS Client (V2.0). Copyright CNRI 1990. All Rights Reserved. 

Please enter your email address in our guest book. . . 
(Your email address?) > KUMQUAT@HILL.COM 

> QUERY KESSLER, GARY 

Trying whois at ds.internic.net... 

The ds.internic.net whois server is being queried: 
No match for "KESSLER and GARY" 

The rs.internic.net whois server is being queried: 

Kessler, Gary C. (GK34) kumquat@HILL.COM 
Hill Associates 
17 Roosevelt Highway 
Colchester, VT 05446 
(802) 655-8633 

The nic.ddn.mil whois server is being queried: 

Kessler, Gary P. (GK15) sa75@TECNETl.JCTE.JCS.MIL 
NAVAL AIR WARFARE CENTER-AD PAX 
Simulation & Control Technology Dept 
SATD 

Patuxent River, MD 2 0670 

301-826-3192 (DSN) 326-3192 (FAX) 301-826-4555 
MILNET TAC user (Issued: ll-jul-1994) 
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TAC authorizing host: TECNET1.JCTE.JCS.MIL (NATC- 3COM) 

Trying mcimail at cnri . reston . va . us . . . 
Trying ripe at whois.ripe.net... 
Trying whois at whois.lac.net... 
No match found for . KESSLER, GARY 

> QUIT 

KIS exiting 

Connection #0 closed 

C:\> 


2.7.3. NETFIND 

NETFIND is another tool that may be used to locate people on the 


network. NETFIND 1 s advantage is that it searches for users by- 
utilizing extant tools such as Finger and SMTP, thus providing the 
potential to find any user on any host without relying on databases. 
For NETFIND to be successful, however, the system manager of existing 
systems must set up Finger and SMTP to respond correctly to NETFIND ' s 
queries. NETFIND is still relatively new and use will grow over 
time . 


NETFIND is a menu-driven, text-based system. Users need to TELNET to 
an available NETFIND server. Once connected, login as "netfind" 
(must be lower-case; no password required) and follow the menu 
prompts. The sample dialogue below shows the search for "Tom 
Maufer", who is known to work at Goddard Space Flight Center ("gsfc") 
at NASA ("nasa.gov"). 

The primary NETFIND server is located at the University of Colorado 
in Boulder (bruno.cs.colorado.edu); alternate servers include: 

archie.au (AARNet, Melbourne, Australia) 

dino.conicit.ve (Nat. Council for Tech. & Sci . Res., Venezuela) 
ds.internic.net (InterNIC Directory & DB Svcs., S. Plainfield, NJ) 
eis.calstate.edu (California State University, Fullerton, CA) 
krnic.net (Korea Network Information Center, Taejon, Korea) 
lincoln. technet . sg (Technet Unit, Singapore) 
malloco . ing .puc . cl (Catholic University of Chile, Santiago) 
monolith.cc.ic.ac.uk (Imperial College, London, England) 
mudhoney.micro.umn.edu (University of Minnesota, Minneapolis) 
netfind.anu.edu.au (Australian National University, Canberra) 
netfind. ee .mcgill . ca (McGill University, Montreal, Quebec, Canada) 
netfind.fnet.fr (Association FNET, Le Kremlin-Bicetre , France) 
netfind.icm.edu.pl (Warsaw University, Warsaw, Poland) 
netfind.if.usp.br (University of Sao Paulo, Sao Paulo, Brazil) 
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netfind.oc.com (OpenConnect Systems, Dallas, Texas) 
netfind.sjsu.edu (San Jose State University, San Jose, California) 
netfind.vslib.cz (Liberec Univ. of Technology, Czech Republic) 
nic.uakom.sk (Academy of Sciences, Banska Bystrica, Slovakia) 
redmont.cis.uab.edu (University of Alabama at Birmingham) 


C:\> TELNET DS.INTERNIC.NET 
SunOS UNIX (ds) 


login: netfind 


Welcome to the InterNIC Directory & Database Server 


Top level choices: 


1. Help 

2 . Search 

3 . Seed database lookup 

4 . Options 

5. Quit (exit server) 


Enter person and keys (blank to exit) --> MAUFER GSFC NASA GOV 

Please select at most 3 of the following domains to search: 

0. gsfc.nasa.gov (goddard space flight center, united states 
national aeronautics and space administration, greenbelt, maryland) 

1. antwrp.gsfc.nasa.gov (compton gamma ray observatory 
science support center, goddard space flight center, united states 
national aeronautics and space administration, greenbelt, maryland) 

2. enemy.gsfc.nasa.gov (compton gamma ray observatory science 
support center, goddard space flight center, united states national 
aeronautics and space administration, greenbelt, maryland) 

3. upolu.gsfc.nasa.gov (goddard space flight center, united 
states national aeronautics and space administration, greenbelt, 
maryland) 

Enter selection (e.g., 2 0 1) --> 0 

( 1) SMTP_Finger_Search: checking domain gsfc.nasa.gov 
Mail is forwarded to tom@stimpy.gsfc.nasa.gov 

NOTE: this is a domain mail forwarding arrangement - mail intended 
for "maufer" should be addressed to "tom@gsfc.nasa.gov" 
rather than "tom@stimpy.gsfc.nasa.gov". 
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( 1) SMTP_Finger_Search: checking host stimpy.gsfc.nasa.gov 
Domain search completed. Proceeding to host search. 


kong . gsf c . nasa . gov 

Login name: maufer In real life: Tom Maufer - CBSI 

Directory: /vault/mauf er Shell: /bin/csh 

Last login Fri Sep 24, 1993 on ttypc from rocinante . gsf c . n 
No unread mail 
No Plan. 


FINGER SUMMARY: 

- The most promising email address for "maufer" 
based on the above finger search is 
tom@gsf c . nasa . gov. 


■* Continue the search ( [n] /y) ? --> N 


Top level choices : 

1. Help 

2 . Search 

3 . Seed database lookup 

4 . Options 

5. Quit (exit server) 

--> 5 

Exiting Netfind server. . . 

Connection #0 closed 
C:\> 
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2.8. Information Servers 
2.8.1. ARCHIE 

Archie is a tool for locating files on the Internet, originally 
developed at the Computer Science Department at McGill University in 
Montreal. Archie allows users to find software, data, and other 
information files that reside at anonymous FTP archive sites across 
the Internet; the name of the program, reportedly, is derived from 
the word "archive" and not from the comic book character. Archie 
tracks the contents of over 1,000 anonymous FTP archive sites 
containing over 2 million files. The Archie server automatically 
updates the information from each registered site about once a month, 
providing relatively up-to-date information without unduly stressing 
the network. 


Before using Archie, you must identify a server address. The sites 
below all support Archie; most (but not all) Archie sites support the 
"servers" command which lists all known Archie servers. Due to the 


popularity of Archie and its high processing demands, many sites 
limit access to non-peak hours and/or limit the number of 
simultaneous Archie users. Available Archie sites include: 


arc 18 ' 




Australia 

arc 16 ' 

' & d " 1 " 

. e vz.um inz.ac.a 

140 ' 


Austria 

arc 18 ' 

. univie.ac.a 


130 1 23 

Austria 

arc 18 ' 

. uqam . ca 


,208.250.10 

Canada 

arc 18 ' 

'^ n8t '^"'" 


214 6 100 

Finland 

arc le. 

. th-darmstadt . de 


.83.22.60 

Germany 

arc 18 ' 

.ac.il ^ 



Israel 

arc 18 ' 

. unipi . it 



ay 

arC t 8 ' 

.wide.ad.jp 


4 3 6 ' 

apan 

arc 16 ' 

. ana . nm . r 


134 1 

orea 




239111 


archie 

uninett^o * 

128 

39 2 20 

Norway 

archie 

. rediris . es 

130. 

.206 .1.2 

Spain 

archie 

. luth. se 

130 . 

.240.18.4 

Sweden 

archie 

. switch. ch 

130 . 

.59.1.40 

Switzerland 

archie 

. ncu.edu. tw 

140. 

.115.19.24 

Taiwan 

archie 

. doc .ic.ac.uk 

146, 

.169.11.3 

United Kingdom 

archie 

. unl . edu 

129. 

. 93 . 1 . 14 

USA (NE) 

archie 

. internic . net 

198. 

.48 .45 . 10 

USA (NJ) 

archie 

. rutgers . edu 

128. 

. 6 . 18 . 15 

USA (NJ) 

archie 

. ans . net 

147 . 

.225.1.10 

USA (NY) 

archie 

. sura . net 

128 . 

.167.254.179 

USA (MD) 
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Archie servers may be accessed using TELNET. When TELNETing to an 
Archie site, login as "archie" (you MUST use lower case) ; just hit 
<ENTER> if a password is requested. 

Once connected, the "help" command assists users in obtaining more 
information about using Archie. Two more useful Archie commands are 
"prog", used to search for files in the database, and "whatis", which 
searches for keywords in the program descriptions. 

In the accompanying dialogue, the "set maxhits" command is used to 
limit the number of responses to any following "prog" commands; if 
this is not done, the user may get an enormous amount of information! 

In this example, the user issues a request to find entries related to 
"mpeg", ISO's Moving Pictures Experts Group video compression 
standard. Armed with this information, a user can use anonymous FTP 
to examine these directories and files. 

The next request is for files with "security" as a keyword 
descriptor. These responses can be used for subsequent "prog" 


commands . 


Exit archie using the "exit" command. At this point, TELNET closes 
the connection and control returns to the local host. 

Additional information about Archie can be obtained by sending e-mail 
to Bunyip Information Systems (archie-info@bunyip.com). Client 
software is not required to use Archie, but can make life a little 
easier; some such software can be downloaded using anonymous FTP from 
the "/pub/archie/" directory at host "ftp.cs.widener.edu" or in 
"/pub/archie/clients/" at "ftp.sura.net". Most shareware and 
commercial Archie clients hide the complexity described in this 
section; users usually connect to a pre-conf igured Archie server 
merely by typing an "ARCHIE" command line. 


** C:\> TELNET 129.93.1.14 
SunOS UNIX (crcnis2) 

** login: archie 
** Password: 

Welcome to the ARCHIE server at the University of Nebraska - Lincoln 

# Bunyip Information Systems, 1993 

** unl-archie> HELP 

These are the commands you can use in help: 
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go up one level in the hierarchy 
? display a list of valid subtopics at the current level 

<newline> 

done, A D, A C quit from help entirely 

<string> help on a topic or subtopic 

Eg. 

"help show" 

will give you the help screen for the "show" command 

"help set search" 

Will give you the help information for the "search" variable. 

The command "manpage" will give you a complete copy of the archie 
manual page . . 
** help> DONE 


unl-archie> SET MAXHITS 5 
unl-archie> PROG MPEG 

# Search type: sub. 

# Your queue position: 1 

# Estimated time for completion: 02:18 

Host ftp.germany.eu.net (192.76.144.75) 
Location : /pub/applications/graphics 

DIRECTORY drwxrwxr-x 512 bytes 00:00 7 Jul 1993 mpeg 

Location: /pub/comp/amiga/gf x 

DIRECTORY drwxr-xr-x 512 bytes 00:00 7 Sep 1993 mpeg 


Host stsci.edu (130.167.1.2) 
Location: /stsci/epa 

DIRECTORY drwxr-xr-x 512 bytes 12:55 21 Jun 1994 mpeg 

Host ftp.nau.edu (134.114.64.70) 
Location: /graphics 

DIRECTORY drwxr-xr-x 512 bytes 04:51 3 Apr 1994 mpeg 

Host gum.isi.edu (128.9.32.31) 

Location : /share/in-notes/media-types/video 

FILE -rw-r--r-- 15 bytes 18:45 11 Jan 1994 mpeg 

** unl- archie > WHATIS SECURITY 

RFC 1037 Greenberg, B.; Keene, S. NFILE - a file access 

protocol. 1987 December; 86 p. 
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RFC 1038 St. Johns, M. Draft revised IP securi 

1988 January; 7 p. 
cops System Security analysis tool 

forktest Find security holes in shell-escapes 

kerberos Host security package 

safe-mkdir mkdir() and security hole *****FIX*** 


unl-archie> EXIT 
# Bye. 

Connection #0 closed 
C:\> 


2.8.2. GOPHER 

The Internet Gopher protocol was developed at the University of 
Minnesota's Microcomputer Center in 1991, as a distributed 
information search and retrieval tool for the Internet. Gopher is 
described in RFC 1436 [1]; the name derives from the University's 
mascot . 

Gopher provides a tool so that publicly available information at a 


host can be organized in a hierarchical fashion, allowing it to be 
perused using a simple menu system. Gopher allows a user to view a 
file on demand without requiring additional file transfer protocols. 
Gopher also has the capability to "link" gophers on the Internet, so 
that each Gopher site can be used as a stepping stone to access other 
sites and reducing the amount of duplicate information and effort on 
the network. 

In many cases, users can access Gopher by TELNETing to a valid Gopher 
location; if the site provides a remote Gopher client, the user will 
see a text -based, menu interface. The number of Gopher sites is 
growing rapidly; as the dialogue below shows, most Gopher sites have 
a menu item that will allow you to identify other Gopher sites. If 
using TELNET, login with the username "gopher" (this MUST be in 
lowercase) ; no password is required. Note that not all Gopher sites 
provide a remote Gopher client; users may need local Gopher client 
software on their system. 

The Gopher server at "ds.internic.net" has a tremendous amount of 
information for the new user, including lists of frequently asked 
questions and pointers to various Internet discussion lists. In the 
sample dialogue below, the remote Gopher client is accessed by 
TELNETing to the host. With the menu interface shown here, the user 
merely follows the prompts. Initially, the main menu will appear; 
selecting item 2 causes Gopher to seize and display the "InterNIC 
Information Services" menu. Move to the desired menu item by typing 
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the item number or by moving the "pointer" (-->) down to the desired 
entry using the <DOWN-ARROW> key on the keyboard, and then hitting 
<ENTER>. To quit the program at any time, press "q" (quit); "?" and 
"u" will provide help or go back up to the previous menu, 
respectively. Users may also search for strings within files using 
the "/" command or download the file being interrogated using the "D" 
command . 

Menu item 7 (selected in the dialogue shown here) is titled 
"Beginners: Start Here", an excellent place for new users to obtain 
information about the Internet, available tools, terms and concepts, 
and, perhaps most importantly, some of the cultural aspects of the 
Internet community. 

Further information about Gopher can be obtained by contacting the 
Internet Gopher Team at the University of Minnesota in Minneapolis 

(gopher@boombox.micro.umn.edu). This is also the site of the first 
Gopher server (consultant.micro.umn.edu). A Gopher-related 
discussion list is maintained at gopher-news@boombox.micro.umn.edu 

(see Section 3.1 for information on subscribing to Internet 
discussion lists) . More information on Gopher clients can be found 
in the Gopher Frequently Asked Questions (FAQ) file, which can be 
downloaded using anonymous FTP in file 


" /pub/usenet/news . answers/gopher-f aq" at the host " rtfm . mit . edu" ; 
this FAQ also lists sources for a number of Gopher clients for a wide 
range of hardware/software platforms. 


SMCVAX$ TELNET DS.INTERNIC.NET 
SunOS UNIX (ds) 


login: gopher 

SunOS Release 4.1.3 (DS) #3: Tue Feb 8 10:52:45 EST 1994 


Welcome to the InterNIC Directory and Database Server. 


Internet Gopher Information Client vl.ll 
Root gopher server: dsO.internic.net 

--> 1. Information About the InterNIC/ 

2. InterNIC Information Services (General Atomics)/ 

3. InterNIC Registration Services (NSI)/ 

4. InterNIC Directory and Database Services (AT&T) / 


Press ? for Help, q to Quit 
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View item number: 2 


Internet Gopher Information Client vl.ll 
InterNIC Information Services (General Atomics) 


1 . README . 

2 . About the Inf oGuide/ 

3. About InterNIC Information Services/ 

4 . About the Internet/ 

5. Getting Connected to the Internet/ 

6 . Beginners : Start Here/ 

7. Using the Internet/ 

8 . Internet Resources/ 

9. Advanced Users: NIC Staff, System Administrators, Programmer 

10. Frequently Asked Questions at InterNIC IS/ ■ 

11. Scout Report/ 

12. WAIS search InfoGuide (and elsewhere) by keyword/ 

13. InfoGuide INDEX. 


Press ? for Help, q to Quit 
View item number: 6 


Page: l/l 


Internet Gopher Information Client vl.ll 
Beginners : Start Here 


--> 1. About This Directory. 

2 . Introductions to the Internet/ 

3 . Glossaries And Definitions/ 

4 . Network Tools/ 

5 . Further Reading/ 

6. Collection of Usenet FAQs/ 

7. Internet Culture and Netiquette/ 

Press ? for Help, q to Quit Page: 1/1 

q 

Really quit (y/n) ? 


Connection closed by Foreign Host 
SMC VAX $ 
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2.8.3. Other Information Servers 

There are a number of other information servers that are growing in 
popularity and use. The problem with being blessed with so much 
information from Archie, Gopher, and other sources is exactly that - 
too much information. To make it easier for users to locate the 
system on which their desired information resides, a number of other 
tools have been created. 

Veronica (Very Easy Rodent -Oriented Net -wide Index to Computerized 
Archives) was developed at the University of Nevada in Reno as an 
adjunct to Gopher. As the number of Gopher sites continues to grow, 
it has become increasingly harder to find information in 
"Gopherspace" since Gopher is designed to search a single database at 
a time. Veronica maintains an index of titles of Gopher items and 
performs a keyword search on all of the Gopher sites that it has 
knowledge of and access to, obviating the need for the user to 
perform a menu-by-menu, site-by-site search for information. When a 
user selects an item from the menu of a Veronica search, "sessions" 
are automatically established with the appropriate Gopher servers, 
and a list of data items is returned to the originating Gopher client 
in the form of a Gopher menu so that the user can access the files. 

Veronica is available as an option on many Gopher servers, including 
"internic.net" . 


Another Gopher -adjunct is Jughead (Jonzy's Universal Gopher Hierarchy 
Excavation And Display) . Jughead supports key word searches and the 
use of logical operators (AND, OR, and NOT) . The result of a Jughead 
search is a display of all menu items which match the search string 
which are located in the University of Manchester and UMIST 
Information Server, working from a static database that is re-created 
every day. Jughead is available from many Gopher sites (including 
"internic.net"), although Veronica may be a better tool for global 
searches . 


Archie and Gopher are primarily used for the indexing of text -based 
files. The World Wide Web (WWW or W3) Project, initiated by the CERN 
Institute for Particle Physics in Geneva, Switzerland, is designed to 
combine aspects of information retrieval with multimedia 
communications. The WWW Project is intended to allow users to access 
information in many different types of formats, including text, 
sound, image, and video. WWW treats all searchable Internet files as 
hypertext documents. "Hypertext" is a new term which merely refers 
to text that contains pointers to other text, allowing a user reading 
one document to jump to another document for more information on a 
given topic, and then return to the same location in the original 
document. The original WWW site is at CERN and may be accessed via 
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Telnet at "nxocOl . cern. ch" . The user will be automatically logged in 
and a help menu can be displayed by entering the "h" command. 

To generally access WWW servers, users must run client software 
called a "browser" . The browser reads documents from WWW servers and 
can access files by FTP, gopher, and other methods. WWW can also 
handle hypermedia documents; "hypermedia" is another new term, 
referring to a file using any medium that contains pointers to 
another medium. WWW browsers, then, are able to display images, 
sound, or animations in addition to text. WWW sources and additional 
information may be accessed via anonymous FTP from the "/pub/WWW" 
directory at " info . cern . ch" or the "/Web" directory at 
" ftp . ncsa . uiuc . edu" . 

The most commonly used WWW browser is Mosaic, developed at the 
National Center for Supercomputer Applications (NCSA) at the 
University of Illinois. Mosaic provides a uniform mechanism for 
finding the location of information, as well as determining the data 
type, presentation method, and linkages to other information. A 
large number of shareware Mosaic clients are available at 
"ftp.ncsa.uiuc.edu". It should be noted that commercial versions of 
Mosaic will also become available for a variety of platforms after 
the summer of 19 94 . 

The Wide Area Information Server (WAIS, pronounced "ways") was 
initiated jointly by Apple Computer, Dow Jones, KMPG Peat Marwick, 


and Thinking Machines Corp. It is a set of free-ware, share-ware, 
and commercial software products for a wide variety of 
hardware/software platforms, which work together to help users find 
information on the Internet. WAIS provides a single interface 
through which a user can access many different information databases. 

The user interface allow a query to be formulated in English and the 
WAIS server will automatically choose the appropriate databases to 
search. Further information about WAIS can be obtained by reading 
the WAIS FAQ, from host "rtfm.mit.edu" in file 
" /pub/usenet/news . answers/wais-f aq" . 

2.9. Uniform Resource Locator Format 

As more and more protocols have become available to identify files, 
archive and server sites, news lists, and other information resources 
on the Internet, it was inevitable that some shorthand would arise to 
make it a little easier to designate these sources. The common 
shorthand that is employed is called the Uniform Resource Locator 
(URL) format. 
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The list below provides information on how the URL format should be 
interpreted for the protocols and resources that have been discussed 
in this document. A complete description of the URL format may be 
found in [2] . 

file : //"host"/"directory"/"f ile-name " 

Used to identify a specific file. E.g., the file "htmlasst" in the 
"edu" directory at host "ftp.cs.da" would be denoted with URL as: 
<URL : file : / /f tp . cs . da/edu/htmlasst> 

ftp://"user" : "password"@"host" : "port"/"directory"/"f ile-name" 
Used to identify an FTP site. E.g.: 
<URL : ftp : //ftp . ef f . org/pub/EFF/Policy/Crypto/*> 

gopher: //"host" : "port "/ "gopher-path" 

Used to identify a Gopher site and menu path. E.g. : 

<URL : gopher : //info . umd . edu : 901/inf o/Government/Factbook92 > 

http : // "host " : "port" / "directory" / " f ile-name" ? "searchpart " 

Used to identify a WWW server location. "http" refers to the 
HyperText Transport Protocol; file names commonly use the ".html" 
extension, indicating use of the HyperText Markup Language. E.g.: 
<URL : http : //info . isoc . org/home . html> 

mailto : "e-mail address" 

Identifies an individual Internet mail address. E.g.: 
<URL : mailto : sds@hill . com> 


telnet : //"user" : "password"@"host" : "port"/ 

Identifies a TELNET site (the trailing "/" is optional). E.g.: 
<URL : telnet/ /envnet :henniker@envnet . gsf c . nasa .gov> 

3 . Discussion Lists 

Among the most useful features of the Internet are the discussion 
lists that have become available to allow individuals to discuss 
topics of mutual concern. Discussion list topics range from SCUBA 
diving and home brewing of beer to AIDS research and foreign policy. 
Several, naturally, deal specifically with the Internet, TCP/IP 
protocols, and the impact of new technologies. 

Most of the discussion lists accessible from the Internet are 
"unmoderated" , meaning that anyone can send a message to the list's 
central repository and the message will then be automatically 
forwarded to all subscribers of the list. These lists provide very 
fast turn-around between submission of a message and delivery, but 
often result in a lot of messages (including inappropriate "junk 
mail") . A "moderated" list has an extra step; a human list moderator 
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examines all messages before they are forwarded to ensure that the 
messages are appropriate to the list and not needlessly inflammatory! 

Users should be warned that some lists generate a significant amount 
of messages each day. Before subscribing to too many lists, be sure 
that you are aware of local policies and/or charges governing access 
to discussion lists and e-mail storage. 

3.1. Internet Discussion Lists 

A list of the known interest groups may be found by Gophering to 
"ds.internic.net". Follow the menu path "InterNIC Information 
Services" | "Using the Internet" | "Basic Internet Services" | 
"Electronic Mail" | "Mailing Lists" to find the 8-part list of lists. 

Be careful if you download these files; the list is nearly 1.5 MB in 
size, listing over 800 lists! Along the way, you will find a wealth 
of other information. 

Mail can be sent to an Internet list at an address with the following 
form : 

1 i s t_name@ho s t_name 

The common convention when users want to subscribe, unsubscribe, or 
handle any other administrative matter is to send a message to the 
list administrator; do NOT send administrivia to the main list 
address! The list administrator can usually be found at: 


1 i s t _name - REQUE S T@ho s t_name 

To subscribe to a list, it is often enough to place the word 
"subscribe" in the main body of the message, although a line with the 
format : 

SUBSCRIBE list_name your_full_name 

will satisfy most mail servers. A similar message may be used to get 
off a list; just use the word "unsubscribe". 

Not every list follows this convention, but it is a safe bet if you 
don't have better information! 

3.2. Usenet 

Usenet, also known as NETNEWS or Usenet news, is another information 
source with its own set of special interest mailing lists organized 
into "newsgroups". Usenet originated on UNIX systems but has 
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migrated to many other types of hosts, although most Usenet servers 
are still UNIX-based. Usenet clients, called "newsreaders", are 
available for virtually any operating system. 

While Usenet newsgroups are usually accessible at Internet sites, a 
prospective Usenet client host must have appropriate newsreader 
software to be able to read news. Users will have to check with 
their local host or network administrator to find out what Usenet 
newsgroups are locally available, as well as the local policies for 
using them. 

Usenet newsgroup names are hierarchical in nature. The first part of 
the name, called the "hierarchy", provides an indication about the 
general subject area. There are two types of hierarchies, called 
"mainstream" and "alternative"; the total number of newsgroups is in 
the thousands. The "news . announce . newusers " newsgroup is a good 
place for new Usenet users to find a detailed introduction to the use 
of Usenet, as well as an introduction to its culture. 

Usenet mainstream hierarchies are established by a process that 
requires the approval of a majority of Usenet members. Most sites 
that receive a NETNEWS feed receive all of these hierarchies, which 
include : 

comp Computers 

misc Miscellaneous 

news Network news 

rec Recreation 

sci Science 


soc 
talk 


Social issues 

Various discussion lists 


The alternative hierarchies include lists that may be set up at any 
site that has the server software and disk space. These lists are 
not formally part of Usenet and, therefore, may not be received by 
all sites getting NETNEWS . The alternative hierarchies include: 

alt Alternate miscellaneous discussion lists 

bionet Biology, medicine, and life sciences 

bit BITNET discussion lists 

biz Various business-related discussion lists 

ddn Defense Data Network 

gnu GNU lists 

ieee IEEE information 

info Various Internet and other networking information 

kl2 K-12 education 

u3b AT&T 3 B computers 

vmsnet Digital 1 s VMS operating system 
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A list of newsgroups may be found at host "rtfm.mit.edu" in the path 
"/pub/usenet/news . answers" ; see the "/active-newsgroups" and "/alt- 
hierarchies" subdirectories. 

There is often some overlap between Usenet newsgroups and Internet 
discussion lists. Some individuals join both lists in these 
circumstances or, often, there is cross-posting of messages. Some 
Usenet newsgroup discussions are forwarded onto an Internet mailing 
list by an individual site to provide access to those users who do 
not have Usenet available. 

Users not connected to Usenet may post messages to a Usenet newsgroup 
using Internet e-mail. First, replace the periods in the Usenet 
discussion list name with hyphens (e.g., the folk music discussion 
list, "rec .music . folk" , would become "rec-music-folk" ) . Then, send 
an e-mail message to: 

newsgroup_name@CS . UTEXAS . EDU 

Usenet news may be read using Gopher. Connect to the host 
"gopher.msu.edu" using the path "News & Weather" | "USENET News" or 
host "gopher.bham.ac.uk" using the path "Usenet News Reader". 

3.3. BITNET/EARN 

Another important set of discussion groups is maintained using a 
program called LISTSERV. LISTSERV is a service provided widely on 
BITNET and EARN (European Academic and Research Network) , although it 
is also available to Internet users. 


LISTSERV commands are placed in the main body of e-mail messages sent 
to an appropriate list server location. To find out what lists are 
available, send a message to "listserv@bitnic.educom.edu" with the 
command "list global" in the main body of the message; whatever you 
place in the "Subject:" field will be ignored. 

Once you have found a list of interest, you can send a message to the 
appropriate address with any appropriate command, including: 


HELP 

SUBSCRIBE list_name your_f ull_name 

UNSUBSCRIBE list_name 

INDEX 

GET file_name 


Get help & a list of commands 
Subscribe to a list 
Unsubscribe from a list 
Get a list of LISTSERV files 
Obtain a file from the server 
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4 . Internet Documentation 

To fully appreciate and understand what is going on within the 
Internet community, users might wish to obtain the occasional 
Internet specification. The main body of Internet documents are 
Request for Comments (RFCs) , although a variety of RFC subsets have 
been defined for various specific purposes. The sections below will 
describe the RFCs and other documentation, and how to get these 
documents . 

NOTE: For complete, up-to-date information on obtaining Internet 
documentation, users should Gopher to "ds.internic.net" and follow 
the path "InterNIC Information Services" | "About the Internet" | 
"Internet Documentation", and then select the desired set of 
documents. This Gopher path is referred to as the "documentation 
root path" in the remainder of this section. 

4.1. Request for Comments (RFCs) 

RFCs are the body of literature comprising Internet protocols, 
standards, research questions, hot topics, humor (especially those 
dated 1 April) , and general information. Each RFC is uniquely issued 
a ■ number which is never reused or reissued; if a document is revised, 
it is given a new RFC number and the old RFC is said to be 
"obsoleted." Announcements are sent to the RFC-DIST mailing list 
whenever a new RFC is issued; anyone may join this list by sending e- 
mail to "rfc-request@nic.ddn.mil". 

RFCs may be obtained through the mail (i.e., postal service), but it 
is easier and faster to get them on-line. One easy way to obtain 
RFCs on-line is to use RFC-INFO, an e-mail-based service to help 


users locate and retrieve RFCs and other Internet documents. To use 
the service, send e-mail to "rfc-info@isi.edu" and leave the 
"Subject:" field blank; commands that may go in the main body of the 
message include: 


HELP 

HELP: ways_to_get_rf cs 

RETRIEVE: RFC 

Doc -ID: RFCxxxx 

LIST: RFC 
[options] 

KEYWORDS: xxx 
AUTHOR: xxx 
ORGANIZATION: 


(Help file) 

(Help file on how to get RFCs) 


(Retrieve RFC xxxx; use all 4 digits) 

(List all RFCs. . . ) 

( . . . [matching the following options] ) 

(Title contains string "xxx") 
(Written by "xxx") 
(Issued by company "xxx") 
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DATED-AFTER: mmm-dd-yyyy 
DATED-BEFORE : mmm-dd-yyyy 

OBSOLETES: RFCxxxx (List RFCs obsoleting RFC xxxx) 

An alternative way to obtain RFCs by e-mail is to send an e-mail 
message to "service@nic.ddn.mil", leaving the "Subject:" field blank. 

In the main body of the message, use one or more of the following 
commands. The RFC index, or a specific reference to an RFC, will 
indicate whether the RFC is available in ASCII text or PostScript 
format. By convention, all RFCs are available in ASCII while some 
are also available in PostScript where use of graphics and/or 
different fonts adds more information or clarity. The instructions 
below show how to get the index; be aware that this file is very 
large, containing the citing for over 1,700 documents. Note that not 
all RFCs numbered below 698 (July 1975) are available on-line: 


SEND HELP (Help file) 

SEND RFC/RFC- INDEX (RFC Index) 

SEND RFC/RFCxxxx.TXT (ASCII version of RFC xxxx) 

SEND RFC/RFCxxxx. PS (PostScript version of RFC xxxx) 


TABLE 1. Some of the RFC Repositories. 

REGION HOST ADDRESS DIRECTORY 

U.S. nic.ddn.mil rfc 

U.S. nisc.jvnc.net rfc 

U.S. ftp.isi.edu in-notes 

U.S. wuarchive.wustl.edu info/rfc 

U.K. src.doc.ic.ac.uk rfc 


Europe funet.fi 
Pacific munnari.oz.au 


rfc 
rfc 


To obtain an RFC via anonymous FTP, connect to one of the RFC 
repositories listed in Table 1 using FTP. After connecting, change 
to the appropriate RFC directory (as shown in Table 1) using the "cd 1 
command. To obtain a particular file, use the "get" command: 


GET RFC -INDEX. TXT local_name 
GET RFCxxxx.TXT local_name 
GET RFCxxxx.PS local_name 


(RFC Index) 

(ASCII version of RFC XXXX) 
(PostScript version of RFC XXXX) 


Finally, check out the path "RFC's (Request for Comments) 11 under the 
documentation root path for the RFC index, complete instructions on 
obtaining RFCs, and a complete set of RFCs. 
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The sample dialogue below, although highly abbreviated, shows a user 
obtaining RFC 1594 (Answers to Commonly asked "New Internet User" 
Questions) using the first three methods described above. 


** SMCVAX$ MAIL 

** MAIL> SEND 

** To: IN%" SERVICE@NIC.DDN.MIL" 

** Subject: 

Enter your message below. Press CTRL/Z when complete, CTRL/C to quit 

** SEND RFC/RFC1594 .TXT 

** A Z 

** MAIL> EXIT 

** SMCVAX$ MAIL 

** MAIL> SEND 

** To: IN% "RFC- INFO@ISI . EDU" 

** Subject: 

Enter your message below. Press CTRL/Z when complete, CTRL/C to quit 

** RETRIEVE: RFC 

** Doc-ID: RFC1594 

** ^Z 

** MAIL> EXIT 

** SMCVAX$ FTP NIC.DDN.MIL 

** Username: ANONYMOUS 

** Password: 

** NIC.DDN.MIL> CD rfc 

** NIC.DDN.MIL> GET rfcl594.txt RFC-1594.TXT 

** NIC.DDN.MIL> EXIT 
SMCVAX$ 


4.2. Internet Standards 


RFCs describe many aspects of the Internet. By the early 1990s, 
however, so many specifications of various protocols had been written 
that it was not always clear as to which documents represented 
standards for the Internet. For that reason, a subset of RFCs have 
been designated as STDs to identify them as Internet standards. 

Unlike RFC numbers that are never reused, STD numbers always refer to 
the latest version of the standard. UDP, for example, would be 
completely identified as "STD-6/RFC-768 . " Note that STD numbers 
refer to a standard, which is not necessarily a single document; an 
STD, therefore, might refer to several RFCs. STD 19, for example, is 
the NetBIOS Service Protocols standard and comprises RFCs 1001 and 
1002; a complete citation for this standard would be "STD-19/RFC- 
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1001/RFC-1002 . " 

The availability of new STDs is announced on the RFC-DIST mailing 
list. STD-1 [14] always refers to the latest list of "Internet 
Official Protocol Standards" . The Internet standards process is 
described in RFC 1602 [6] and STD notes are explained in RFC 1311 
[15] . 

STDs can be obtained as RFCs via anonymous FTP from any RFC 
repository. In addition., some RFC sites (such as "nic.ddn.mil") 
provide an STD directory so that STD documents can be found in the 
path "/STD/xx.TXT" , where "xx" refers to the STD number. 

STD documents may be obtained as RFCs using the methods described in 
Section 4.1. STDs may also be obtained via the RFC-INFO server using 
the "RETRIEVE : STD" and "Doc-ID: STDxxxx" commands. Also, check out 
the path "STD's (Standard RFCs)" under the documentation root path 
for the STD index, complete instructions on obtaining STDs, and a 
complete set of STDs. 

4.3. For Your Information Documents 

The For Your Information (FYI) series of RFCs provides Internet users 
with information about many topics related to the Internet. FYI 
topics range from historical to explanatory to tutorial, and are 
aimed at the wide spectrum of people that use the Internet . The FYI 
series includes answers to frequently asked questions by both 
beginning and seasoned users of the Internet, an annotated 
bibliography of Internet books, and an explanation of the domain name 
system. 

Like the STDs, an FYI number always refers to the latest version of 
an FYI. FYI 4, for example, refers to the answers to commonly asked 
questions by new Internet users; its complete citation would be "FYI- 


4/RFC-1594." The FYI notes are explained in FYI 1 [9] 


FYIs can be obtained as RFCs via anonymous FTP from any RFC 
repository. In addition, some RFC sites (such as "nic.ddn.mil") 
provide an FYI directory so that FYI documents can be found in the 
path "/FYI/xx.TXT" , where "xx" refers, to the FYI number. 

FYI documents may be obtained as RFCs using the methods described in 
Section 4.1. FYIs may also be obtained via the RFC-INFO server using 
the "RETRIEVE: FYI " and "Doc-ID: FYIxxxx" commands. Also, check out 
the path "FYI's (For Your Information RFCs)" under the documentation 
root path for the FYI index, complete instructions on obtaining FYIs, 
and a complete set of FYIs. 
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4.4. RARE Technical Reports 

The Reseaux Associes pour la Recherche Europeenne (RARE) is the 
Association of European Research Networks and their users. RARE ' s 
charter is to promote and participate in the creation of a high- 
quality European computer communications infrastructure for the 
support of research endeavors . RARE member networks use Open Systems 
Interconnection (OSI) protocols and TCP/IP. Since the summer of 
1993, to promote a closer relationship between RARE and the IETF, 
RARE Technical Reports (RTRs) are also published as RFCs. 

RTR documents may be obtained as RFCs using the methods described in 
Section 4.1. RTRs may also be obtained via the RFC-INFO server using 
the "RETRIEVE: RTR" and "Doc-ID: RTRxxxx" commands. Also, check out 
the path "RTR 1 s (RARE Technical Report RFCs)" under the 
documentation root path for the RTR index, complete instructions on 
obtaining RTRs, and a complete set of RTRs. They may also be 
obtained via anonymous FTP from "ftp.rare.nl". 

NOTE: As of December 1994, RARE and EARN have merged to form TERENA 
(Trans-European Research and Education Network Association) . 

5 . Perusing the Internet . . . 

This guide is intended to provide the reader with a rudimentary 
ability to use the utilities that are provided by TCP/IP and the 
Internet. By now, it is clear that the user's knowledge, ability, 
and willingness to experiment are about the only limits to what can 
be accomplished. 

The next step is to explore the nooks and crannies of the network. 
One software tool that will users in this quest is the Merit Computer 
Center's (Ann Arbor, MI) "Cruise of the Internet", available at no 
cost from the host "nic.merit.edu" using FTP. For more information, 
read the "readme" files in the directories "internet/resources/ 


cruise. mac" and "internet/resources/cruise. dos" for Mac and PC 
versions, respectively. For general information about resources at 
this site, see the READ. ME file in the root directory or send e-mail 
to "nic-info@nic.merit.edu". 


Several RFCs provide invaluable information about finding things on 
the Internet. One of the best such sources is FYI 10/RFC 1402, 
titled "There's Gold in them thar Networks! -or- Searching for 
Treasure in all the Wrong Places" [11] , an excellent guide for 
someone who wants to look around the Internet for a wide range of 
material. Other good sources include the "Hitchhiker's Guide to the 
Internet" (RFC 1118) [7] and the "Guide to Network Resource Tools" 
(FYI 23/RFC 1580) [3] . Answers to frequently asked questions for 
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both new and experienced users of the Internet may be found in FYI 
4/RFC 1594 [10] and FYI 7/RFC 1207 [8] , respectively. 

There are many other sources that cite locations from which to access 
specific information about a wide range of subjects using such tools 
as FTP, Telnet, Gopher, and WWW. These include: 

o The INTERNET SERVICES LIST, maintained by Scott Yanoff of the 
University of Wisconsin in Milwaukee and updated at least once a 
month. This list can be obtained at <URL : f tp : //f tp . csd . uwm . edu/ 
pub/inet . services . txt> or <URL : gopher : //csd4 . csd . uwm. edu/Remote 
Information Services/Special Internet Connections> . 

o An excellent starting point for searching the World Wide Web is to 
point your WWW browser at "http://www.ncsa.uiuc.edu/SDG/Software 
/Mosaic/ StartingPoints/NetworkStartingPoints .html " . 

o The Scout Report is a weekly service by the InterNIC Information 
Services team. To subscribe to the Scout Report mailing list, send 
e-mail to "majordomo@is.internic.net" and place the line "subscribe 
scout-report" in the main body of the message. Optionally, Gopher 
to "ds.internic.net" and follow the path "InterNIC Information 
Services" | "Scout Report" or point your WWW browser at 
"http : //www. internic . net/inf oguide . html " . 

o "The INTERNET Yellow Pages" by Harley Hahn and Rick Stout [28] . 

More books and specialized articles came out about the Internet in 
1993 and 1994 than in all previous years (squared!). Some of them 
are directly related to finding your way around, or finding things 
on, the Internet; a very partial list includes: 

o "The Internet Directory" by Eric Braun [21] 

o "The MAC Internet Tour Guide", "The PC Internet Tour Guide", and 
"The Windows Internet Tour Guide" by Michael Fraase [24, 25, 26] 


o "The Internet Navigator" by Paul Gilster [27] 

o "Zen and the Art of the Internet" by Brendan Kehoe [2 9] 

o "The Whole Internet User's Guide & Catalog" by Ed Krol [31] 

o "INTERNET: Getting Started" by April Marine, Susan Kirkpatrick, 
Vivian Neou, and Carol Ward [3 3] 

o "Finding it on the Internet: The Next Challenge for Librarianship" 
by Brian Nielsen [34] 
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o "Navigating the Internet" by Richard Smith and Mark Gibbs [35] 

A much more comprehensive list of Internet-related books may be found 
in FYI 19/RFC 1463 [5] . 

Finally, Carl Malamud has written a delightful book called "Exploring 
the Internet: A Technical Travelogue" [32], chronicling not the 
Internet as much as the people who built it and use it. This book 
will not teach you how to perform an anonymous FTP file transfer nor 
how to use Gopher, but provides insights about our network (and 
Carl's gastro-pathology) that no mere statistics can convey. 

6 . Acronyms and Abbreviations 


ASCII American Standard Code for Information Interchange 

BITNET Because It's Time Network 

DDN Defense Data Network 

DNS Domain Name System 

EARN European Academic Research Network 

FAQ Frequently Asked Questions list 

FTP File Transfer Protocol 

FYI For Your Information series of RFCs 

HTML HyperText Markup Language 

HTTP HyperText Transport Protocol 

ICMP Internet Control Message Protocol 

IP Internet Protocol 

ISO International Organization for Standardization 

NetBIOS Network Basic Input/Output System 

NIC Network Information Center 

NICNAME Network Information Center name service 

NSF National Science Foundation 

NSFNET National Science Foundation Network 

RFC Request For Comments 

RARE Reseaux Associes pour la Recherche Europeenne 

RTR RARE Technical Reports 

SMDS Switched Multimegabit Data Service 

SMTP Simple Mail Transfer Protocol 


STD 

TCP 

TTL 

UDP 

URL 

WAIS 

W3 

WWW 


Internet Standards series of RFCs 

Transmission Control Protocol 

Time-To-Live 

User Datagram Protocol 

Uniform Resource Locator 

Wide Area Information Server 

World Wide Web 

World Wide Web 
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7. Security Considerations 

Security issues are not discussed in this memo. 
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